ponerle los piquetes al UI de Qt
- iconos en los window corners
- find icon en el search window
- in search window, save columns width and search parameters to configuration (def reject(self))

make logo

dynamic playlist handling:
- en este momento, si la configuracion cambia, por X, Y o Z motivo, el config dialog no esta reflejando ese hecho.  Esto significa que si se agrega borra o renombra un dynamic playlist, no se modifica el combobox del dialog box... Por si acaso, en _the_real_run se esta haciendo el chequeo de si existe o no exist eel subquery, y si se esta moviendo en la configuracion para que sea None.
- interfaz de usuario deberia actualizarse cuando se crean / borran dynamic playlists. pero el problema es que amarok no guarda el archivo del dynamic playlists cuando se los modifica.

- reenable pydcop or find the right pykde and retry again the unicode problem and the pyqt problem.  the unicode problem was that before passing arguments to dcop_call they needed to be turned into iso-8859-1, which caused problems with files with filenames encoded in iso-8859-1.  and the pyqt problem is the double qapplication (one gui, one no gui) problem..  Creo que tengo la solucion.  Todos los argumentos que sean string deben pasarse primero por una funcion que los convierta a unicode usando el getfilesystemencoding o algo asi.

- wherever a config value is touched/written/changed, we need to raise my custom homegrown config_changed signal. peinar las sources a ver si este es el caso.

- investigate cual es la influencia del factor volume_diff en el codigo fuente de GJay, y mirar como incorporarlo a mi hua.

Falta robustez para manejar los symlinks (cuando se indexean (recordemos que amarok puede tener una cancion y un simlink a esa misma cancion en la coleccion), cuando se hace el super dj loop tambien).

falta una funcion y un llamado a esa funcion que purge de la database los archivos que ya no existen en el disco... o en la coleccion?  no se aun como sera esa hua.

DEbe ser posible que, cuando una cancion no pudo descodificarse (por ejemplo tenemos una version vieja de soganalysis que no decodifica FLACs), se la marque, cosa que cuando tengamos una version nueva (detectemos un cambio en la version de esa nota) podamos reintentar rescanear SOLO ESAS CANCIONES. Osea un flag "could not be scanned".  Al iniciar sacariamos la "version" actual de songanalysis (una especie de version string "1.2.1+mp3+flac+ogg"), la comparariamos con la version de la ultima ejecucion, y si son diferentes, buscariamos las que no pudieron escanearse, y las eliminariamos de la tabla analysis para que sean reescaneadas en el proceso subsiguiente.

BTW, el chequeo de interface es ortogonal, por supuesto, y debe permanecer, cosa que cuando cambie la interfaz, se reescanee todo.  Probablemente amarok-songanalysis deba exigir determinada interfaz X.  O tal vez podemos solucionar ese problema haciendo comandos paralelos.  Songanalysis2, songanalysis3... who knows.  that's kind of far away for now.

y tenemos que añadir a la configuracion y al search algo para que haya tempo drift, cosa que el playlist se vaya haciendo mas rapido o mas lento cada vez

el algoritmo del tempo esta MAL.  segun yo el algoritmo correcto es hacer que la cancion pase por un bandpass filter < 200hz, y "reproducirla" detectando beats, haciendo una lista de los tiempos entre beats (probablemente estoy se pueda programar en mmpython), y sacando la moda de esa lista, ese debe ser el tempo.  buscar info sobre raytracing beat detection.
algoritmo tempo sugerido x mi:
dado un bufer, recorrer el bufer y buscar beats.  para cada beat encontrado, almacenar la diferencia de intensidad y la posicion absoluta (tiempo).  cuando esto se haya concluido, coger la lista de tiempos y hacer una lista de (TsubN - TsubN-1).  Obtener la moda de esta lista.   Yata.

revisar el algoritmo de spectrum similarity.  pvh puede ayudar.

The following is obsolete:
- detect modified files, so i can re-analyze them.  there is no way to do this even with a database schema change because if a file got changed (e.g. replaced by another file), the database has no info on that.  this may actually require the construction of the uniq ID tracker code branch patch.
   if modified_date > scan_date:
       rescan (whatever that implies - regenerating the extattrs or rereading them)
because:
amarok saves the last modified date in the database.  We can use that to determine whether a file has been modified, and rescan it (basically removing it from the statistics table, and letting the loop scan it when it's due).  If it has the extattrs, we can collect them (this means that the file's contents did not change).  we would of course need to store the mtime on our own table, so as to compare them
... on tags.url = analysis.url ... where tags.modified_date != analysis.modified_date
and so we'd delete them from the database (no se si todas de golpe o 1 x 1) y rescanearlas.
todavia queda el tema de ver como hacemos para identificar si EL CONTENIDO de un archivo ha cambiado, para saber si invalidar los extattrs y reescanear el archivo, o algo asi.  osea hay que describir dos procesos distintos: cuando hay extattrs y cuando no hay extatrs.



database maintenance. ver si esto funciona en pgsql, mysql y sqlite, para hacer un common ground y poder amplicficar las tablas y modificarlas conforme vayamos avanzando de version en version, y no emitir comandos x las guevas.
[rudd-o@andrea ~]$ dcop amarok collection query "show tables"
album
amazon
analysis
artist
directories
genre
images
related_artists
statistics
tags
year




escribir un script que coteje y vea si los contenidos de los extattrs matchean con los contenidos de la database


Prefer songs which share the same:
        Tempo   <--------------|----------------> Music style
Tempo:
	( o ) Keep the same tempo
        (    ) Change the tempo by [  1 -+] BPM for each added song
for config dialog auto dj mode


-----------------------

necesitamos unirnos a una biblioteca que permita leer mp3 tags y cosas asi para no depender de la base de datos de amarok.  asi get_song nos entrega un verdadero songobject, y podemos armar un verdadero cache de musica que no tengamos que estar requeryando a la DB a cada rato y es mucho mas rapido y descongestionamos DCOP y tampoco dependemos de que una cancion en particular este en la coleccion.  Esto se podria lograr creando una implementacion alternativa de songobject que se presente cuando exista mmpython por ejemplo.

-----------------

make plugin interface as a class, not global functions in a module!
eso da la chance de hacer un stub module que explique, cuando el usuario pretenda usar alguno de los comandos, que necesita instalar alguna hua.  eso puede hacerse a posteriory.

-----------

el search window deberia tambien poder circunscribirse a un solo dynamic playlist.

------------------


Compare song similarity - select 2 or more songs and compare similarity.  the similarity window comparison must accept drops, and the user may choose any of these songs to be the "start song" for the similarity comparison.

mas tarde una huevada para ver graphicamente el spectrum y comparar entre canciones.

necesitaremos eventualmente un contraption en el background song analyzer o el collection expert que permita emitir una señal "analyzed" a un slot que reciba como parametro un filename. asi podemos hacer mas modular y menos interwined el codigo.

una huevada para buscar canciones con el mismo nombre y huas asi.

una huevada para buscar canciones mutuamente relacionadas, osea dependiendo de que he estado oyendo, entonces la relaciono con una cancion que vino despues o algo asi.  o tal vez audioscrobbler sea suficientemente bueno.


---------------------


find songs similar by name

--------------

reportar a los devs de amarok que el right click context menu que pueden añadir los plugins deberia aplicar a TODOS lados donde se puede hacer right click a un track cualquiera.